For the first time, I gave two talks on one day. The honor was mine to present “Exploratory Testing with the Team, a Journey Worth Taking” and “Testing RPG: Do You Have What it Takes to Beat the Final Boss in Testing?!” at Testit conference in Malmö, Sweden.
In this blog post, I’ll focus on two things. Did it suck to present two talks on one day as an introvert? And I’ll go over the questions people always ask me at the end of talks.
Giving two talks on one day as an introvert
Not gonna lie, I was not looking forward to presenting. Talking for 30 minutes straight takes a lot out of me. Some people receive energy from the act of talking, but I don’t. This clashes with the ambition I have to get my stories out there, so I’ll do it anyway. As long as I don’t give talks too often, it’s fine to pay the price of exhaustion.
If this sounds ridiculous to you, I’m glad for you.
I prepared myself for this day by practicing my talks quite a lot. I think I went over both talks 4 times in rehearsal, tweaked some things, and felt confident that my preparation had been enough.
I cannot stress this enough: prepare your talks well, and it’ll be a much more enjoyable experience giving the talk.
I used to half arse the prep, and it showed in my talks. English is not my first language and when I was searching for words I had the habit of replacing the “uhhh” with curse words like “fuck” and “shit”. I don’t mind curse words, but some people in the audience do. I did mind how it made me feel, though: like I hadn’t delivered a good enough talk.
The solution: put effort in and practice, to feel confident. Don’t come at me with “I have ADHD, I can only prep my talks at the last possible moment” bullshit. What are you, a toddler? I also struggle with motivation A LOT, but prioritizing and planning for long term goals has a HUGE payoff. You are selling yourself short if you keep making up excuses as to why you can’t. Create a reasonable plan, and stick to it.
It also turned out that I had been overthinking how hard it would be to give two talks in one day. It was fine. Because of all the prep work, I was not nervous. I felt confident and capable. Talk one went well. I don’t know (yet) if the audience agrees, but to me, it felt good. I wasn’t that tired and only had to wait 1.5 hours to give the next talk. That turned out to be a good thing. The second talk also went well, and I hope the audience agrees here too. I got my stories across, it felt good to do so, and I felt very satisfied that my prep work paid off. No struggles with the English language, no real nerves to speak off.
It wasn’t until the drinks and dinner later that the exhaustion hit me. We came back to the hotel at 9PM, and I was asleep before 10PM. Nine (!) hours of sleep later, and I felt ready to take on a new day.
I want to thank the TestIt conference organizers for a very smooth experience. Amanda, especially, was very quick to respond to my questions. Also, a special shout-out to the food quality. I don’t think I ever ate this fancy at a conference. Swedish people share my love for potatoes, for which I am grateful too.
Questions from the audience
Let’s go over some questions I get a lot after the Exploratory Testing with the Team talk.
The management summary of that talk is: one tester doesn’t scale (even if they write automated tests). We are all biased, including testers. Testers face the impossible task to “test it all” and they can’t and shouldn’t. It’s better when the whole team thinks about testing and does testing tasks. You’ll generate more ideas to search for new information that will inform decisions to improve the software. Exploratory Testing is a great approach to search for new information, as long as you do it in a structured way. As a tester, you can lead the way in teaching people how to do exploratory testing, and you can set up team testing sessions.
Q: How do you prove the value of exploratory testing and its outcome?
The value of testing is that it can yield new information that is valuable to the team and/or the company. However, most of the time, the information is only really useful when it’s acted upon. If, as a tester, you keep finding bugs, but they all get ignored, was it valuable? It certainly won’t feel that way!
So, I’d say that if you do Exploratory Testing and find new information, and the information is ACTED upon, it’s useful. That proves to me that the information is valuable.
Bonus effects from exploratory testing with the team: team building, shared responsibility, it can possibly find more issues compared to when fewer people test (although you can’t prove this!).
Salty answer: really? No one bats an eye if you piss away hours in meetings with your whole team, but proving the value of the act of testing is a must? Bruh.
Q: KPI’s something something. “How many bugs did you find with Exploratory Testing?”
I’m sorry, I only have a salty answer here. If you are counting the number of bugs as the measurable outcome of testing (and by extension exploratory testing) you don’t understand shit. This is only a motivation for people to log the most mundane issues they find, to crank up the number. If you want me to find as many bugs as I can, I can. But, this will only lead to a colossal waste of time for all people involved. Let’s focus on finding USEFUL INFO, shall we? Let’s worry less about whether it classifies as a bug, a feature, a problem. Let’s worry less about how to measure all the stuff we do.
Q: How do you get the whole team together to do this? How do you claim the time? It costs money!
Again, it baffles me how nobody cares if you piss away time in meetings when there’s no bias for action, but actually getting people to DO testing is a problem?
Sure, I’d take some time to chat with your product owner about this initiative. It helps if they are on board.
Other than that, I wouldn’t gatekeep myself too much. I planned two hours with my team and informed them of the purpose. That it wasn’t a meeting, that they were expected to do actual testing. I guess I was lucky that all my team members were willing and open to do all the tasks required to get the software to production, including testing.
The first session yielded so many bugs and new information that the value was clear.
Q: What do you do with bugs you aren’t going to solve?
Toss them away. Kill your darlings. Zero (known) bug policy, baby!
What happens to bugs that are put on a backlog? They go there to die. To be ignored. You either fix a bug, or you don’t. Because it’s not important, or perhaps too complicated. Because….reasons that make sense in your context.
But carrying a list of bugs with you just to get some “peace of mind” is silly.
Trust me, the world will keep turning even if you delete your precious logged bugs. If you find some of them again, then you can decide again to fix them.
The baller move is to learn enough about programming so that you can fix some smaller bugs yourself.
Q: How do you get developers to join exploratory team testing? Not all of them are going to be willing to do it.
Yup, that’s true. I have experienced that myself as well.
I would personally focus on the people who are open to it.
I have put a lot of energy into arguing with “unwilling” developers, and it was a total waste of time. The arguments against the team exploratory testing were always the same: “I can’t test, or think like a tester” (oh, suddenly you can’t learn a new skill? Bollocks), “I don’t want to do it” (ok toddler, have a cookie then), “I think all testing should be automated” (ok, I think all programming should be automated).
To preserve your own sanity, I want you to make this your mantra: some people are just assholes. What do you do with assholes? You ignore them. Don’t engage, they just like arguing. There’s no winning.
I have had a much greater time at work by focusing on people who like to make the software better and who agree with me that there’s a big variety of tasks that need to be done to make that happen, including testing. People who are open to learn new skills and don’t hide behind their stupid little job title.
If there’s literally no one around you willing to try this….Well, I don’t know what to tell you. Maybe get out of that environment.
Those are the questions I’ve heard a lot after giving this talk.
Some of you will not agree with me on the zero bug policy, and that’s fine.
That was it for giving talks for this year. I have only done 3. Perfectly balanced, as all things should be.
I’ll see what the year 2025 brings for conferences. Hope to see you there!